Klassische Projektabwicklung

Die Projektabwicklung von Turn-Key-Anlagen durchläuft verschiedene, zeitlich teilweise überlappende Phasen:
offshore: Design (grob/fein), Procurement (Einkauf), Logistik (Versand und Lagerung)
onshore: Bauarbeiten (civil works), Transport zur Baustelle, Lagerung, Aufbau, Inbetriebnahme, Kundenabnahme, Gewährleistungsphase

Dazu kommt in der Vorphase die Angebotserstellung und während der Laufzeit des Projektes Durchführung von Schulungen, Factory Acceptance Tests (FATs), die Erstellung und Verwaltung zahlreicher Anlagendokumente in ihren unterschiedlichen Revisionsständen, bis hin zu den As-Built-Ausgabeständen zum Projektabschluss.
Während der Projektlaufzeit fällt umfangreiche Korrespondenz an, sowie ein regelmäßiges Projektreporting zu Kunden, zusätzlich meist auch firmenintern.
Die kommerzielle Abwicklung (Cash-In) des Projekts hängt eng mit den Lieferungen und dem Projektfortschritt, sowie dem Erreichen vertragsgemäßer Meilensteine zusammen.
Bei den üblichen Projektproblemen kommt es häufig aus den verschiedensten Gründen zu Terminverzug, welcher ein späteres Claimverfahren notwendig macht.
All diese Aktivitäten beschäftigen ein Abwicklungsteam unter der Führung des Projektleiters über mehrere Monate, nicht selten sogar über Jahre.
Im Laufe dieses Prozesses kommt es zu Bearbeiterwechseln, sowohl auf Seiten der abwickelnden Firma, als auch auf Seiten des Kunden. Mit jedem Wechsel entstehen Brüche in der Bearbeitung, projektspezifischer Know-How-Verlust entsteht, das Fehlerrisiko und die Bearbeitungszeit erhöht sich zumindest kurz nach dem Wechsel und mit einer anwachsenden Projektlaufzeit ist zu rechnen.

Projektabwicklung 2.0 mit PMT

Die Projektinhalte werden durch den Vertrag bestimmt. Die Phasen des Projektes laufen unverändert wie im klassischen Fall.
Es ändert sich jedoch die Art der Bearbeitung. Mit PMT kann das komplette Projekt auf einer konsistenten Datenbasis verwaltet werden.
Also:
Statt einer Vielzahl von Tools, die jedes für sich gekauft, installiert, gepflegt und bedient werden müssen bietet PMT eine gemeinsame Datenbasis, auf die für die verschiedenen Themen zugegriffen wird. Die Bedienoberfläche ist eine intelligente Browseranwendung, ohne besondere Systemanforderungen. Alle Projektmitarbeiter sehen dieselben Daten, eventuell angepaßt durch spezifische Zugriffsrechte. Ein Grundprinzip bei PMT lautet: Keine Redundanz! Jedes Datum nur einmal eingeben, und zwar an der Stelle des ersten Auftretens!
Beispiel:
Das Projekt beschliesst den Kauf eines Transformators. Nach Auswahl des Lieferanten wird aus dem PMT heraus für diesen Lieferanten eine Internetseite generiert, deren Link an den Lieferanten gesendet wird. Dort wird der Lieferant seine gesamten Daten und Dokumente hinterlegen, wie: PMT ist entstanden aus der gelebten Projekt-Praxis. Viele andere Tools dagegen sind aus der Theorie entstanden, und grundsätzlich gut geeignet, firmeninterne Managementpräsentationen zu unterstützen, erzeugen in der Praxis jedoch meist wertlosen Zusatzaufwand.
Jedes Tool lebt von seinen Daten. Wenn es häufig benutzt und gepflegt wird, so ist der Datenbestand aktuell und die Informationen werden Nutzen bringen. Sobald der Anwender den Nutzen erkennt, wird er das System auch intensiv nutzen (positives Feedback). Andernfalls veraltet der Datenbestand und damit sinkt auch die Qualität der Daten und der Nutzen für den Anwender (negatives Feedback).

Im Gegensatz zu der oft gepredigten Lehrmeinung, dass jedes Projekt ein Unikat ist, setzt die PMT Philosophie auf die Gemeinsamkeiten, die alle Projekte haben. Man kann und muss Projekte clustern und typisieren, um die Gemeinsamkeiten zu erkennen. Aber auch branchenübergreifend gibt es immer noch zahlreiche Gemeinsamkeiten.
Die Analyse, warum Projekte scheitern, ist von sehr großem Interesse, um daraus Rückschlüsse zu ziehen. Leider wird diese Analyse in den Firmen entweder gar nicht oder nur halbherzig gemacht. Im besten Fall werden ein paar Lessons-Learnt Folien angefertigt, um den Vorgaben Genüge zu tun, aber für echte Veränderungen bleibt in klassischen Projektorganisationen keine Zeit.
Auch mentale Blockaden verhindern eine ehrliche Diskussion. Man möchte nicht gerne die Probleme zur Kenntnis nehmen und daher verdrängt man das Ganze und überläßt es dem 'Qualitätsbeauftragten'. Allein die Existenz dieses Mitarbeiters sollte schon ein Warnsignal sein, dass die Organisation Qualität outgesourced hat!

Noch ergiebiger als eine Auswertung gescheiterter (was ist das?) Projekte wäre eine Auswertung der Schwierigkeiten in den Projekten. Wann ist ein Projekt gescheitert? Sicherlich dann, wenn es abgebrochen wurde, aber im engeren Sinne muss man es dann als gescheitert betrachten, wenn es nicht das eingeplante Ergebnis erbringt.
Das Scheitern eines Projektes ist nur in wenigen Fällen auf ein einzelnes Ereignis zurückzuführen, und dann wäre die Analyse auch einfach. In den weitaus meisten Fällen ergibt sich ein Scheitern aus einer Vielzahl von Verzögerungen und kleinen Hindernissen, die jedes für sich oft gar nicht als relevantes Problem wahrgenommen werden. In der Kombination führen sie jedoch zu erheblichem Verzug und entsprechenden Mehrkosten. Die Wirkungskette (Zeit und Kosten) ist hierbei nicht linear, sondern kann sprunghaft verlaufen.
Einige Beispiele: